Computer systems for connected devices such as cell phones, personal data assistants (PDAs) and set top boxes for televisions are becoming more flexible. Newer systems allow software to be downloaded and executed. The downloaded software may not be entirely trustworthy and yet may share resources with existing, trusted software. Various techniques have been proposed and implemented to therefore restrict the access of untrusted software to prevent it from disrupting the operation of the system. However, the purpose of these systems is at odds with another goal of allowing software components to communicate with one another.
One known mechanism for allowing software components to communicate with one another is the Remote Procedure Call (RPC). This mechanism allows a computer program running on one host to cause code to be executed on another host and return the results to the first program. Typically, RPC protocols are used to implement a client-server model of distributed computing.
Various editions of the JAVA™ Platform provide a mechanism known as Remote Method Invocation (RMI) for performing an RPC to communicate between objects. In RMI, the methods of remote JAVA™ objects can be invoked from another Java virtual machine, possibly on a different host. As depicted in FIG. 1, RMI 100 essentially allows communication between JAVA™ Virtual Machine (JVM) A 102, and JVM B 104. JVM A 102 and JVM B 104 may be running on the same physical machine, or may be running on different machines and connected over a local area network (LAN) or an Internet Protocol (IP) network connection or other communication medium. The application program interface (API) that implements RMI 100 handles the details of the communication between virtual machines.
Because RMI includes all the necessary components and security measures for communicating between different machines over different protocols, RMI is complex and can be unwieldy for small devices, as RMI provides many features that are simply not needed in most connected devices. Therefore, the RMI API is not included in the Personal Basis Profile (PBP) for JAVA™ 2 Platform Micro Edition (J2ME).
The conventional model for JAVA™ applications assumes that only one application is executing in a given virtual machine, and this application is in complete control of its lifecycle, which can include killing the virtual machine it is running in. To accommodate the limited processing and memory resources available in the typical connected device and yet allow multiple programs to run concurrently, the JAVA™ Community Process (JCP) has proposed the use of a programming model referred to as Xlets.
Xlets are similar to applets, which can be run by an Internet web browser, or servelets, which can be run by a web server, in that a plurality of Xlets can run at the same time in a single JVM, and their lifecycle can be controlled by another program. In the case of applets, the other program is generally a web browser. Running multiple programs in a single instance of a JVM can improve overall system performance and scalability by sharing some of the virtual machine's internal data structures. Xlets may be managed by a stand-alone application manager.
Since a plurality of Xlets may be operated by a single JVM, a mechanism was deemed necessary to protect sets of Xlets that may be harmed by a malicious downloaded Xlet. Thus, the concept of a Logical Virtual Machine (LVM) was developed. The LVM is a resource context structure that provides a mechanism for referencing the code from one or more programs that share the same resource or object. Associating related threads with a particular LVM allows the related threads to be terminated together when they start to misbehave, e.g., by causing a denial of service attack.
However, protecting Xlets by separating them into different LVMs meant placing them out of communication with each other, which is undesirable. Therefore, some mechanism was required to permit Xlets to communicate to each other from between different LVMs or, more generically, resource domains. U.S. Pat. No. 6,829,772, issued Dec. 7, 2004 and hereby incorporated by reference, presents a method now referred to as Inter-Xlet Communication (IXC) that allows Xlets to communicate with each other from different LVMs. It should be noted that, when that patent was filed, the term “Xlet” had yet to be coined and so Xlets are referred to therein by the term “applets,” which was used generically.
The IXC API is now part of the J2ME PBP. FIG. 2 represents IXC 110 between two Xlets, Xlet A 112 and Xlet B 114, which each reside in different LVMs. However, this IXC implementation is limited to what is referred to as a single-process, multi-virtual machine (MVM) paradigm. In this paradigm, each LVM 116, 118 is executed in a single process JVM 120 and shares a common address space. The IXC implementation (not shown) takes advantage of the common address space for sharing instances between each LVM.
An isolation context for executing Xlets is now termed “isolate.” In one realization of isolates, each isolate runs in its own process and therefore has its own address space. This may be referred to as the “multiple process, MVM” paradigm. The JAVA™ Application Isolate API is defined in JAVA™ Specification Request 121 (JSR-121) which is incorporated herein by reference. Because the previous mechanism for IXC relied on a common address space among Xlets, it is not structurally possible to implement in this new paradigm.
Thus, a new IXC mechanism is needed that will provide required security measures to prevent denial of service attack, while at the same time permit RPCs between Xlets located in different isolates on a common JVM. The new mechanism should also provide reliable garbage collection and efficient type checking. Furthermore, the IXC implementation should be optimized for an isolate implementation wherein isolates exist on the same machine, but in separate address spaces.